Tech Multimedia News 4

home *** CD-ROM | disk | FTP | other *** search

/ Tech Multimedia News 4 / Tech Multimedia News #4 (1994).iso / share / dos / chiaro / chils.doc < prev next >

Wrap

Text File | 1993-03-18 | 59.5 KB | 1,250 lines

CHILS 1.1 DOCUMENTATION ======================= James W. Birdsall 03/19/93 0. CONTENTS ----------- 0. CONTENTS 1. INTRODUCTION 1.1 Quick Reference 1.2 Copyright, License, and Warranty Disclaimer 2. USAGE 2.1 Targets 2.1.1 Wildcards 2.2 Options 2.2.1 -t Type 2.2.2 -s Complex Search 2.2.3 -v Verbose 2.2.4 -f Front End 2.2.5 -n No Truncate 2.2.6 -w Width 2.2.7 -# Version 2.2.8 -? Help 3. CONFIGURATION FILE 4. OUTPUT 4.1 GIF87a 4.2 GIF89a 4.3 IMG_1 4.4 JFIF1.01 4.5 SUNRAS 4.6 TARGA 4.7 PBM, PGM, PPM, PBM_RAW, PGM_RAW, PPM_RAW 4.8 XBM 4.9 WIN2BMP 4.10 OS2BMP11 4.11 WIN3BMP 4.12 OS2BMP20 4.13 PCX 5. THE END 1. INTRODUCTION --------------- CHILS is a program of the Chiaro suite. It produces a quick listing of information about image files of many formats. Since it is not specific to any one format, it has been given the CHI- prefix instead of a particular format prefix. It automatically recognizes a variety of image formats. The information printed includes file name, file format, file size, and some details of image size, colors, etc., depending on what information the format contains and how accessible it is. The Chiaro suite is also available for UNIX systems. 1.1 Quick Reference ------------------- This is a quick summary of the usage and options of CHILS. Invoking CHILS with the option "-?" will produce a similar summary. Complete explanations may be found in section 2. usage: chils [options] [target] [target target...] target filename, filename with wildcards, or path. Wildcards are *, ?, and ranges or groups specified in []. A range or group may be complemented with ^ or !. -tformat TYPE: Only files of the specified format will be processed. Ignores the -v option. Multiple -t options may be specified. The identifiers recognized (case insensitive) are: identifier meaning ----------------------------- GIF87a GIF87a files GIF89a GIF89a files GIF Any GIF file, either GIF87a or GIF89a IMG_1 GEM IMG version 1 file IMG Any GEM IMG file (only version 1 known to exist) JFIF101 JPEG File Interchage Format version 1.00/1.01 JFIF Any JFIF file (only versions 1.00-1.01 known to exist) SUNRAS Sun raster files TARGA TARGA files PBM_NORM Portable BitMap files, ASCII format PBM_RAW Portable BitMap files, raw format PBM Any Portable BitMap file PGM_NORM Portable GrayMap files, ASCII format PGM_RAW Portable GrayMap files, raw format PGM Any Portable GrayMap file PPM_NORM Portable PixMap files, ASCII format PPM_RAW Portable PixMap files, raw format PPM Any Portable PixMap file XBM X11 BitMap files WIN2BMP MS-Windows 2.x bitmap files OS2BMP11 OS/2 1.1-1.3 bitmap files WIN3BMP MS-Windows 3.x bitmap files OS2BMP20 OS/2 2.0 bitmap files BMP Any BMP file PCX_25 PCX version 2.5 files PCX_28 PCX version 2.8 files without palettes PCX_28P PCX version 2.8 files with palettes PCX_30 PCX version 3.0 files PCX Any PCX file -spattern COMPLEX SEARCH: Allows complicated Boolean searches based on height, width, colors, and format. Format keywords are as for the -t option, above. Decimal numbers are allowed. Other operators are: ( ) parentheses = equal H height } greater than { less than W width }= greater or equal {= less or equal C colors + logical and , logical or F file length Example: -s(W}=640+H}=480),(GIF+C=256) searches for images at least 640 by 480, or any size GIF with 256 colors. -v VERBOSE: Prints a line for every file checked, whether the format was recognized or not. -f FRONT END: For use as front end for GIFSTRIP or other Chiaro suite programs. Prints list of matching files on stdout. Ignores the -v option. -n NO TRUNCATE: Do not remove path from filename in display. -w[n] WIDTH: Override width of display. -# VERSION: Prints version information on internal modules. -? HELP: Prints a usage message. Options are case insensitive, and may not be combined. 1.2 Copyright, License, and Warranty Disclaimer ----------------------------------------------- The Graphics Interchange Format(c) is the Copyright property of CompuServe Incorporated. GIF(sm) is a Service Mark property of CompuServe Incorporated. SunOS is a trademark of Sun Microsystems Inc. Targa and TrueVision are probably trademarks of AT&T. MS-Windows is probably a trademark of Microsoft. OS/2 is a registered trademark of IBM. Other terms in this document may be trademarks or service marks of or copyright by various corporations and organizations. CHILS is not in the public domain. All the files are copyright 1993 by James W. Birdsall, all rights reserved. The following license applies to the entire Chiaro suite, which is made up of all the files listed in the file MANIFEST. Permission is granted to do the following: You may freely redistribute this archive, so long as it contains all the files listed in the file MANIFEST, intact and unmodified. You may use the programs contained in this archive for a period of 30 days for evaluation purposes. Payment of the $10 shareware fee (which covers all the programs in the Chiaro suite) licenses you to use the Chiaro suite beyond the evaluation period. This license-to-use specifically includes use by bulletin board systems and other commercial or private information services. Registered users will also receive update notices and bug reports, and are entitled to use future versions without further payment. The contents of the distribution archive, and all other related files, information, and services are provided "as is" and without warranty. To the extent permitted by applicable law, the author disclaims all warranties, express or implied, including but not limited to, any implied warranty of merchantability or fitness for a particular purpose. While effort has been made to ensure that the files, information, and services are accurate and correct, the author shall not be liable for damages arising out of the use of or inability to use this product, including but not limited to, loss of profit, data, or use of this software, or special, incidental, or consequential damages or other similar claims, even if the author has been specifically advised of the possibility of such damages. Some states do not allow the exclusion of incidental or consequential damages, so the foregoing limitation may not apply to you. Information on contacting the author is provided at the end of this file. 2. USAGE -------- CHILS may be called with zero or more options interspersed with zero or more targets. All options are scanned before any file searching is done, so order of options and targets is unimportant. 2.1 Targets ----------- A target can consist of a filename (optionally with path), a path, or a filename with wildcards (again, optionally with path). In the case of a filename, that file is processed. In the case of a path, all files in the specified directory are processed. In the case of a filename with wildcards, all files in the appropriate directory (the current directory if no path is given) matching the wildcards are processed. If no targets are given, all files in the current directory are processed. If the format of a file is recognized, various information about the file will be printed to the standard output. This output may be redirected using the MS-DOS redirection operators. If the format of a file is not recognized, no output is generated for that file unless the VERBOSE option has been specified. 2.1.1 Wildcards --------------- Wildcards are much closer to the UNIX standard than the MS-DOS standard. The characters * and ? retain their ordinary meanings but matching is much more intelligent. For example, *A.GIF will match LENNA.GIF but not CHESS.GIF, whereas under ordinary MS-DOS wildcards, *A.GIF would match both. Further, groups and ranges of characters may be specified in brackets []. For example, PIC0[1-5].GIF will match any filename starting with "PIC0", then containing any one of the characters "1", "2", "3", "4", or "5", and ending with ".GIF". PIC0[1-5A-F].GIF will match the names described before or those with the characters "A", "B", "C", "D", "E", or "F" between "PIC0" and ".GIF". A range or group may be complemented with the characters "^" or "!". For example, PIC0[^1-5].GIF will match any name with one character between "PIC0" and ".GIF" unless that character is "1", "2", "3", "4", or "5". Note that wildcards are only allowed in the filename portion, not the path portion. "\PICTURES\NEWGIF*\*.GIF" is illegal and an error message will be issued. 2.2 Options ----------- CHILS has a variety of options to modify its function, including options to allow selection of specific files according to format, image size, etc. These options are described below. Options are case-insensitive ("-v" is the same as "-V") and may not be combined ("-ftGIF89a" will not have the desired effect, since only the "-f" will be recognized; "-f -tGIF89a" should be used instead). 2.2.1 -t Type ------------- This option causes only files of the specified format to be processed. Multiple -t options may be specified; files of all the specified types will be processed. There must not be a space between the "-t" and the format identifier. The -v VERBOSE option, if present, is ignored. The complete list of recognized format identifiers is printed out in the usage message. Format identifiers are case insensitive. At present, the following format identifiers are recognized: identifier meaning -------------------------------- GIF87a GIF87a files GIF89a GIF89a files GIF Any GIF file, either GIF87a or GIF89a IMG_1 GEM IMG version 1 file IMG Any GEM IMG file (only version 1 known to exist) JFIF101 JPEG File Interchange Format versions 1.00 and 1.01 JFIF Any JFIF file (only versions 1.00 and 1.01 known to exist) SUNRAS Sun raster files TARGA TARGA files PBM_NORM Portable BitMap files, ASCII format PBM_RAW Portable BitMap files, raw format PBM Any Portable BitMap file PGM_NORM Portable GrayMap files, ASCII format PGM_RAW Portable GrayMap files, raw format PGM Any Portable GrayMap file PPM_NORM Portable PixMap files, ASCII format PPM_RAW Portable PixMap files, raw format PPM Any Portable PixMap file XBM X11 BitMap files WIN2BMP MS-Windows 2.x bitmap files OS2BMP11 OS/2 1.1-1.3 bitmap files WIN3BMP MS-Windows 3.x bitmap files OS2BMP20 OS/2 2.0 bitmap files BMP Any BMP file PCX_25 PCX version 2.5 files PCX_28 PCX version 2.8 files without palettes PCX_28P PCX version 2.8 files with palettes PCX_30 PCX version 3.0 files PCX Any PCX file 2.2.2 -s Complex Search ----------------------- This option allows specification of a complicated Boolean search pattern, including search on file format, image height, image width, number of colors in the image, and file size. Only files which meet the specified search criteria are processed. Any -t TYPE options are ignored, as is the -v VERBOSE option. There must not be a space between the "-s" and the search pattern, or within the search pattern. If there is more than one -s option specified, only the last one on the command line will have any effect. The search pattern may include the following operator characters: operator meaning -------------------------------- ( parentheses, for grouping ) } greater than }= greater than or equal = equal { less than {= less than or equal + Boolean AND , Boolean OR The operator characters work on the following elements: element meaning -------------------------------- H height of image, in pixels W width of image, in pixels C number of colors in image F size of file, in bytes format identifiers as used with the TYPE option decimal numbers The somewhat unusual operator character selection is to avoid conflicting with characters reserved by COMMAND.COM or other command processors, while at the same type using symbols which have some relation to their assigned meaning. For example, the traditional greater than, less than, and Boolean OR symbols ('>', '<', and '|') are all I/O redirection operators under COMMAND.COM and many other command processors; therefore they could not be used since they are parsed out by the command processor and CHILS will never see them! The operators and elements may be combined in various ways. Examples: -sW}=640 searches for images whose width is greater than or equal to 640 pixels. -s(W}=640+H}=480) searches for images whose width is greater than or equal to 640 pixels AND whose height is greater than or equal to 480 pixels. The parentheses are not actually necessary. -s(W}=640+H}=480),(GIF+C=256),(F}500000) searches for any image whose width is greater than or equal to 640 pixels AND whose height is greater than or equal to 480 pixels, OR any image which is of GIF format (GIF87a or GIF89a) AND which contains 256 colors, OR any image whose file size is greater than 500,000 bytes. The overall effect is to search for very large images (large in pixels or bytes), or any GIF image with lots of colors. 2.2.3 -v Verbose ---------------- The -v VERBOSE option causes CHILS to print a line for every file processed, whether or not the file format was recognized. If the file format was not recognized, a message "ERROR: file ... is of unknown format" is printed, where ... is the name of the file. 2.2.4 -f Front End ------------------ This option causes CHILS to simply print a list of filenames of recognized format (subject to selection criteria specified by -s and -t options) on the standard output, separated by newlines. It ignores the -v VERBOSE option. This output of this mode is intended as input for other Chiaro suite utilities which do not have the complex selection capabilities of CHILS. These utilities automatically detect redirection of their standard input and attempt to read a list of files from it. For example, suppose it is desired to process all GIF89a-format files in the current directory through the utility GIFSTRIP. The following command line accomplishes this: CHILS -f -tGIF89a | GIFSTRIP CHILS searches all the files in the current directory and prints the names of all GIF89a-format files on its standard output (use of the -t TYPE option is explained above). The standard output of CHILS is connected to the standard input of GIFSTRIP via the MS-DOS pipe operator, '|'. GIFSTRIP detects that its standard input has been redirected (is not the keyboard) and reads the names of files to be processed from its standard input instead of taking them from the command line. While the output of this mode is not intended for direct human consumption, it can be useful for producing lists of filenames. To simply produce a list of all GIF89a files in the current directory, and save the list in the file LIST89A.TXT, do: CHILS -f -tGIF89a > LIST89A.TXT 2.2.5 -n No Truncate -------------------- CHILS normally removes the path from filenames which contain one, which gives it a better chance of fitting the filename on the same line as the information about the file. However, this could lead to confusion in the case of files with the same name in different directories, so this option is provided which prevents removal of the path. In either case (with or without path), if the filename does not fit on the same line as the rest of the information, it is placed on the line immediately following, right-justified. 2.2.6 -w Width -------------- CHILS normally determines the width of the screen in columns automatically, defaulting to 80 if the screen is less than 80 columns wide or if the number seems to large to be accurate. This option allows the user to manually set the width, in case CHILS retrieves a bad but plausible width or refuses to believe in an extra-wide screen. If no number is supplied (i.e. just "-w"), the width is set to 80; if a number is supplied (e.g. "-w160"), the width is set to that number, except that numbers less than 80 are treated as 80. 2.2.7 -# Version ---------------- This option is intended more for bug reporting purposes than anything else. It causes CHILS to print the version numbers and compilation dates of its component modules. No files are processed, and all other options are ignored. 2.2.8 -? Help ------------- This option, or any syntax error on the command line, causes a usage message to be displayed. No files are processed, and all other options are ignored. 3. CONFIGURATION FILE --------------------- Many image formats do not include signatures which identify them uniquely. The only way to identify these formats is by filename. Most formats have one or more filename extensions which are commonly used to identify that format. To accomodate as wide a variety of naming systems as possible, CHILS uses a configuration file which contains lists of formats and extensions which identify those formats. Extensions may also be included for those formats which have identification signatures (GIF and SUNRAS), to avoid false recognition. If extensions for those formats are included, only files with those extensions will be checked for the signature; otherwise all files will be checked. The configuration file must be named CHILS.CFG. CHILS searches for it first in the current directory. If there is no such file in the current directory, CHILS checks for the existence of an environment variable CHIHOME. If this variable exists, it is assumed to contain the directory in which the configuration file resides. For example, if the configuration file is C:\VIEW\CHIARO\CHILS.CFG, CHIHOME would be C:\VIEW\CHIARO. Finally, if the DOS version is 3.0 or greater, CHILS searches in the directory containing the CHILS executable. If the DOS version is below 3.0 and the configuration file is not in the current directory, CHIHOME must be set. This three-layer system allows local configuration files which override the main configuration file, and allows the main configuration file to be anywhere, not necessarily in the same directory as the CHILS executable. If the configuration file does not exist, a warning message is issued. Formats for which CHILS needs an extension list, but which do not have an entry in the configuration file, will not be processed. Blank lines in CHILS.CFG are ignored. Comments begin with '#'. The '#' must be the first non-whitespace character on the line, but it does not have to be in the first column. Both spaces and tabs are recognized as whitespace. Comments are terminated by the end of the line. Each format entry consists of one line. The syntax of the entry is: format_name extension [[,] extension...] The format name and extensions are not case sensitive. The line may contain leading whitespace, before the format name. The format name must be separated from the first extension by at least one space or tab. There must be at least one extension on the line. Additional extensions may be separated by commas and/or whitespace. The entry is terminated by the end of the line. Warnings are generated when CHILS encounters an unrecognized format name, an entry with only a format name (no extension list), an extension longer than three characters, or a zero-length extension (caused by two commas in a row, for example). Format identifiers presently recognized by CHILS are: GIF, IMG, JFIF, SUNRAS, TARGA, PBM, PGM, PPM, XBM, BMP, and PCX. 4. OUTPUT --------- The output generated by CHILS varies according to the format of the image, but the meaning of some columns is constant. GIF87A -G 110871 381 x 480 @ 64 C~80 ssb28c.gif GIF89A -G- 2657 640 x 480 @ 16 C~1 ASnone 89aillus.gif GIF89A -G- 62318 640 x 480 @ 16 C~40 AS49/64 grney5.gif IMG_1 - 62630 960 x 960 @ 2 C~54 AS 85/85 P1 example1.img JFIF101 - 18314 264 x 341, 3 @ 8 C~5 AS 1/ 1 lat1.jpg JFIF101 - 44046 976 x 768, 1 @ 8 C~7 AS 1/ 1 slf1n.jpg JFIF101 - 62139 597 x 480, 3 @ 8 C~8 72 x 72 dpi jol1.jpg SUNRAS CV 4435 80 x 50 @ 256 C~90 ML=768 encoded.im8 SUNRAS C- 32150 871 x 871 @ 2 C~33 jupiterc.im1 SUNRAS SV 4800 80 x 50 @ 256 ML=768 standard.sun SUNRAS S- 1568 16 x 32, 24 bit stndrd24.im24 TARGA -UM- 4756 80 x 50 @ 246 T1 A0 type1.tga TARGA -UC- 1554 16 x 32, 24 bit T2 A0 type2.tga TARGA -UB- 186 24 x 7 @ 256 T3 A0 type3.tga PBM_RAW R 29 24 x 7 @ 2 feep-raw.pbm PGM_RAW R 180 24 x 7 @ 256 MaxVal = 255 feep-raw.pgm PPM_RAW R 59 4 x 4, 24 bit MaxVal = 255 feep-raw.ppm PBM_NORM N 355 24 x 7 @ 2 feep.pbm PGM_NORM N 519 24 x 7 @ 16 MaxVal = 15 feep.pgm PPM_NORM N 189 4 x 4 @ 4096 MaxVal = 15 feep.ppm XBM 182 24 x 7 @ 2 'feep' feep.xbm WIN3BMP -- 5078 80 x 50 @ 256 256color.bmp WIN3BMP -- 630 32 x 32 @ 16 argyle.bmp PCX_30 RC 4715 80 x 50 @ 256 C~114 CX 80,CY 50 color.pcx PCX_30 RC 191 24 x 7 @ 8 C~100 CX 24,CY 7 feepgray.pcx PCX_30 RC 152 24 x 7 @ 2 C~114 CX 24,CY 7 feepmono.pcx The first column is always the format (see the list under the -t option above). The second column, if present, is a group of flags whose meaning varies according to the image (see below). The third column is the filesize. Next is the width and the height of the image (or a reasonable approximation) in pixels, then the number of colors in the image in a format which depends on the image. After that is miscellaneous format-dependent information; frequently a compression ratio is given, indicated by "C~". The last column is always the filename. If the filename is too long to fit on the line, it is put on the line immediately following, right justified. 4.1 GIF87a ---------- GIF87A EG 53882 398 x 548 @ 16 C~49 bar4.gif GIF87A -G 110871 381 x 480 @ 64 C~80 ssb28c.gif GIF87A -- 59392 320 x 240 @ --- C~-- tt.gif The GIF87A format has two flags. The first is "E" if extra characters are detected on the end of the file, or "-" if not. The second is "G" if the file contains a global color table, or "-" if not. Note that the "E" flag is only a quick and dirty check for extra characters on the end of the file. If the last character of the file is the GIF Terminator, "-" is displayed; if it is not, "E" is displayed. This check will be fooled if the file contains extra characters which happen to end with the GIF Terminator character. GIFSTRIP and GIFCHECK offer reliable detection of extra characters (and, in the case of GIFSTRIP, removal thereof). The width and height displayed are for the logical screen, not the actual image. Typically the image or images in the file will be the same size as the logical screen, but this is not required. Unfortunately, it is not possible to extract the size of the actual image or images without parsing much of the file, which is beyond the scope of CHILS. The number of colors shown is the size of the global color table, or "---" if there is no global color table. Images typically do not use all the colors in the global color table; the number should be regarded as an upper limit on the colors in the actual image rather than the actual figure. GIFCHECK can determine the number of unique colors actually used. The only format-dependent display is the compression ratio. "--" is displayed if no global color table is present, since the calculation relies on the size of that table. The compression ratio is calculated by multiplying the height by the width, then multiplying that result by the number of bits required to represent the colors in the image (based on the size of the global color table), and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the present file size is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. Note that the value displayed may be radically incorrect if the file contains multiple images, if the file contains extension blocks, if the image uses a local color table, if the image is smaller than the logical screen size, or if there are very many extra characters on the end of the file. In the first example, the format is GIF87a. There were extra characters detected, and the file contains a global color table. The logical screen is 398 pixels wide by 548 pixels high. The global color table contains 16 colors. The file is 53882 bytes long. (((398 * 548) * 4) / 8) = 109052; (53882 / 109052) = 0.49, so the file is 49% of the size of the uncompressed image, in theory. The filename is "bar4.gif". In the second example, the format is GIF87a. No extra characters were detected on the end of the file, and the file contains a global color table. The logical screen is 381 pixels wide by 480 pixels high. The global color table contains 64 colors. The file is 110871 bytes long. (((381 * 480) * 6) / 8) = 137160. (110871 / 137160) = 0.80, so the file is 80% of the size of the uncompressed image, in theory. The filename is "ssb28c.gif". In the third example, the format is GIF87a. There were no extra characters detected. The file does not contain a global color table. The file is 59392 bytes long. The logical screen is 320 pixels wide by 240 pixels high. Since there is no global color table, the number of colors in the global color table is undefined and "---" is displayed. Since there is no global color table, the compression ratio cannot be calculated and "--" is displayed. The filename is "tt.gif". 4.2 GIF89a ---------- GIF89A -G- 2657 640 x 480 @ 16 C~1 ASnone 89aillus.gif GIF89A -G- 62318 640 x 480 @ 16 C~40 AS49/64 grney5.gif The GIF89A format has three flags. The first is "E" if extra characters are detected on the end of the file, or "-" if not. The second is "G" if the file contains a global color table, or "-" if not. The third is "S" if the global color table is sorted in order of decreasing importance, or "-" if not. Note that the "E" flag is only a quick and dirty check for extra characters on the end of the file. If the last character of the file is the GIF Terminator, "-" is displayed; if it is not, "E" is displayed. This check will be fooled if the file contains extra characters which happen to end with the GIF Terminator character. GIFSTRIP and GIFCHECK offer reliable detection of extra characters (and, in the case of GIFSTRIP, removal thereof). The width and height displayed are for the logical screen, not the actual image. Typically the image or images in the file will be the same size as the logical screen, but this is not required. Unfortunately, it is not possible to extract the size of the actual image or images without parsing much of the file, which is beyond the scope of CHILS. The number of colors shown is the size of the global color table, or "---" if there is no global color table. Images typically do not use all the colors in the global color table; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. GIFCHECK can determine the number of unique colors actually used. Format-dependent displays for GIF89a are the compression ratio and aspect ratio, in that order. If no global color table is present, "--" is displayed for the compression ratio, since the calculation relies on the size of that table. The compression ratio is calculated by multiplying the height by the width, then multiplying that result by the number of bits required to represent the colors in the image (based on the size of the global color table), and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the present file size is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. Note that the value displayed may be radically incorrect if the file contains multiple images, if the file contains extension blocks, if the image uses a local color table, if the image is smaller than the logical screen size, or if there are very many extra characters on the end of the file. The aspect ratio is given in 64ths. If there is no aspect ratio, "none" is displayed. In the first example, the format is GIF89a. There were no extra characters detected, the file contains a global color table, and the global color table is not sorted. The file is 2657 bytes long. The logical screen is 640 pixels wide by 480 pixels high. The global color table contains 16 colors. (((640 * 480) * 4) / 8) = 153600; (2657 / 153600) = 0.01, so the file is 1% of the size of the uncompressed image, in theory. No aspect ratio is given. The filename is "89aillus.gif". This is an example of a file where the compression ratio is misleading. This file is actually a demonstration of the GIF89a format's text extension capabilities, and does not contain an image as such. Most of the file is occupied by the global color table. In the second example, the format is GIF89a. There were no extra characters detected, the file contains a global color table, and the global color table is not sorted. The file is 62318 bytes long. The logical screen is 640 pixels wide by 480 pixels high. The global color table contains 16 colors. (((640 * 480) * 4) / 8) = 153600; (62318 / 153600) = 0.40, so the file is 40% of the size of the uncompressed image, in theory. The aspect ratio is 49:64. The filename is "grney5.gif". 4.3 IMG_1 --------- IMG_1 - 62630 960 x 960 @ 2 C~54 AS 85/85 P1 example1.img Note that there are many file formats named "IMG", a situation which is confusing at best. CHILS recognizes only the GEM IMG format. The IMG_1 format has one flag. It is "L" if the IMG header is extended (to contain a palette, for example), or "-" if the header is of normal length. The maximum number of colors in the file is calculated from the number of bit planes; the actual number of colors used may be less than the number shown. Format-dependent displays for IMG_1 are the compression ratio, aspect ratio, and pattern length, in that order. The compression ratio is computed by multiplying the height by the width, then multiplying that result by the number of bit planes, and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the present file size minus the header length is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. The compression ratio is reasonably accurate. Since the header length is known accurately, that number is subtracted from the filesize to get a more accurate compressed size. The compression ratio will only be incorrect if there are junk characters on the end of the file. The aspect ratio is always present. The numbers also represent the width and height, respectively, of a pixel, in microns. 85 microns is approximately equivalent to 300 pixels per inch. The pattern length in pixels is used when decompressing the image. In the example, the format is IMG version 1. The header is of standard length. The file is 62630 bytes long. The image is 960 pixels wide by 960 pixels high. The file may contain up to 2 colors. (((960 * 960) * 1) / 8) = 115200; ((62630 - 16) / 115200) = 0.54, so the file is 54% of the size of the uncompressed image. The pixels are 85 microns wide by 85 microns high, which means the aspect ratio is 85:85. The pattern length is 1. The filename is "example1.img". 4.4 JFIF1.01 ------------ JFIF101 - 18314 264 x 341, 3 @ 8 C~6 AS 1/ 1 lat1.jpg JFIF101 - 44046 976 x 768, 1 @ 8 C~7 AS 1/ 1 slf1n.jpg JFIF101 - 62139 597 x 480, 3 @ 8 C~8 72 x 72 dpi jol1.jpg The JFIF 1.0 and 1.01 formats differ minimally; CHILS treats them as identical. The JFIF101 format has one flag. It is "T" if a thumbnail image is present in the file, or "-" if not. The number of colors is expressed as the number of "components" (usually 3 or 1) by the number of bits per component (usually 8). Images with three components are full-color, while images with one are, by convention, grayscale. Format-dependent displays for JFIF101 are the compression ratio and aspect ratio or pixel density, in that order. The compression ratio is computed by multiplying the height by the width, then multiplying that result by the number of components times the bits per component, and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the present file size is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. Note that the image itself is actually compressed even more than shown, since the present file size includes all the headers and other, non-image information present in the file. JFIF101 files contain either an aspect ratio or a pixel density. If an aspect ratio is present, it is expressed as a fraction. If pixel density is present instead, it is displayed as the horizontal density by the vertical density followed by the units, which are either "dpi" (pixels/dots per inch) or "dpcm" (pixels/dots per centimeter). In the first example, the format is JFIF version 1.0/1.01. There is no thumbnail image. The file is 18314 bytes long. The image is 264 pixels wide by 341 pixels high. The image has three components per pixel, and each component has eight bits. (((264 * 341) * (3 * 8)) / 8) = 270072. (18314 / 270072) = 0.06, so the file is 6% of the size of the uncompressed image. This image has an aspect ratio instead of pixel density information; the aspect ratio is 1:1. The filename is "lat1.jpg". In the second example, the format is JFIF version 1.0/1.01. There is no thumbnail image. The file is 44046 bytes long. The image is 976 pixels wide by 768 pixels high. The image has one component per pixel, and the component has eight bits. (((976 * 768) * (1 * 8)) / 8) = 749568. (44046 / 749568) = 0.05, so the file is 5% of the size of the uncompressed image. This image has an aspect ratio instead of pixel density information; the aspect ratio is 1:1. The filename is "slf1n.jpg". In the third example, the format is JFIF version 1.0/1.01. There is no thumbnail image. The file is 62139 bytes long. The image is 597 pixels wide by 480 pixels high. The image has three components per pixel, and each component has eight bits. (((597 * 480) * (3 * 8)) / 8) = 859680. (62139 / 859680) = 0.07, so the file is 7% of the size of the uncompressed image. This image has pixel density information instead of an aspect ratio; the pixel density is 72 pixels per inch horizontally and 72 pixels per inch vertically. 4.5 SUNRAS ---------- SUNRAS CV 4435 80 x 50 @ 256 C~90 ML=768 encoded.im8 SUNRAS C- 32150 871 x 871 @ 2 C~33 jupiterc.im1 SUNRAS SV 4800 80 x 50 @ 256 ML=768 standard.sun SUNRAS S- 1568 16 x 32, 24 bit stndrd24.sun Sun Raster files are a format developed by Sun Microsystems for use on their workstations. The SUNRAS format has two flags. The first is "O" for 'old' format files (left over from ancient versions of SunOS), "S" for standard files, "C" for compressed files, "R" for 24-bit files with reversed color-component order, "T" for "tiff <-> standard rasterfile" (don't ask me), "I" for "iff (TAAC format) <-> standard rasterfile" (again, don't ask me), and "E" for 'experimental' formats. The second flag is "-" if the file does not have a colormap, "V" if the colormap is in 'vector' format (all red components grouped together, all green components grouped together in the same order, etc.), or "R" if the colormap is in 'raw' format (usually RGB triples). The number of colors is expressed either as a number or as the number of bits per pixel, depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. Format-dependent displays for SUNRAS are the compression ratio (if a compressed format) and the length of the colormap in bytes (if a colormap is present), in that order. The compression ratio is computed by multiplying the height by the width, then multiplying that result by the number of bits per pixel, and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the size of the compressed data (maintained in the file header) is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. The compression ratio is accurate unless the file is corrupted. If a colormap is present, the length in bytes is displayed as "ML=nnn". In the first example, the format is Sun Raster. The image is compressed and has a vector-style colormap. The file is 4435 bytes long. The image is 80 pixels wide by 50 pixels high. The colormap has 256 entries. The compressed image data is 90% of the size of the uncompressed data. The colormap is 768 bytes long. The filename is "encoded.im8". In the second example, the format is Sun Raster. The image is compressed and does not have a colormap. The file is 32150 bytes long. The image is 871 pixels wide by 871 pixels high. The image has one bit of color information per pixel, so the number of colors is displayed as 2. The compressed image data is 33% of the size of the uncompressed data. The filename is "jupiterc.im1". In the third example, the format is Sun Raster. The image is the standard (uncompressed) type and has a vector-style colormap. The file is 4800 bytes long. The image is 80 pixels wide by 50 pixels high. The colomap has 256 entries. The colormap is 768 bytes long. The filename is "standard.sun". In the fourth example, the format is Sun Raster. The image is the standard (uncompressed) type and does not have a colormap. The file is 1568 bytes long. The image is 16 pixels wide by 32 pixels high. The image has 24 bits of color information per pixel. The filename is "stndrd24.sun". 4.6 TARGA --------- TARGA -UM- 4756 80 x 50 @ 246 T1 A0 type1.tga TARGA -UC- 1554 16 x 32, 24 bit T2 A0 type2.tga TARGA -UB- 186 24 x 7 @ 256 T3 A0 type3.tga The Targa format was developed by AT&T in conjunction with their TrueVision graphics hardware. The TARGA format has four flags. The first is "-" if the file contains an image or "N" if not. The second is "-" for no image, "U" for an uncompressed image, "R" for a runlength-encoded image, or "C" for an LZW-compressed image. The third is "-" for no image, "M" for a colormapped image, "B" for a grayscale image, or "C" for a full-color image. The fourth flag indicates the scan-line interleave of the image: "-" for noninterleaved, "2" or "4" for two- or four- way interleaving, or "R" for a reserved value. The number of colors is expressed either as a number or as the number of bits per pixel. If the image is colormapped, the length of the colormap is displayed. If the image is not colormapped (either grayscale or full-color), either a number or the number of bits is displayed depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. Format-dependent displays for TARGA are the compression ratio (if a runlength-encoded or LZW-compressed format), the format type "Tn", the number of attribute bits per pixel "An", "M" if an unnecessary colormap is included in the file, and "I" if the file has an ID field. The compression ratio is computed by multiplying the height by the width, then multiplying that result by the number of bits per pixel, and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the present file size minus the header, ID field, and colormap lengths is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. The compression ratio should be accurate unless the file is corrupted or there are junk characters on the end of the file. In the first example, the format is Targa. The file contains an image, which is uncompressed, uses a colormap, and is noninterleaved. The file is 4756 bytes long. The image is 80 pixels wide by 50 pixels high. The colormap contains 246 colors. The format type is 1. There are 0 attribute bits per pixel. The filename is "type1.tga". In the second example, the format is Targa. The file contains an image, which is uncompressed, is full-color, and is noninterleaved. The file is 1554 bytes long. The image is 16 pixels wide by 32 pixels high. The image contains 24 bits of color information per pixel. The format type is 1. There are 0 attribute bits per pixel. The filename is "type2.tga". In the third example, the format is Targa. The file contains an image, which is uncompressed, is grayscale, and is noninterleaved. The file is 186 bytes long. The image is 24 pixels wide by 7 pixels high. The image contains 8 bits of color information per pixel, so the number of colors is displayed as 256. The format type is 3. There are 0 attribute bits per pixel. The filename is "type3.tga". 4.7 PBM, PGM, PPM, PBM_RAW, PGM_RAW, PPM_RAW -------------------------------------------- PBM_RAW R 29 24 x 7 @ 2 feep-raw.pbm PGM_RAW R 180 24 x 7 @ 256 MaxVal = 255 feep-raw.pgm PPM_RAW R 59 4 x 4, 24 bit MaxVal = 255 feep-raw.ppm PBM_NORM N 355 24 x 7 @ 2 feep.pbm PGM_NORM N 519 24 x 7 @ 16 MaxVal = 15 feep.pgm PPM_NORM N 189 4 x 4 @ 4096 MaxVal = 15 feep.ppm These formats were developed by Jef Poskanzer for his Portable Bitmap (later Portable Bitmap Plus) package. The formats were designed to be easily transferable between machines and easily usable on widely differing machines. There are three basic types, PBM (Portable BitMap, black and white only), PGM (Portable GrayMap, grayscale), and PPM (Portable PixMap, full-color), each of which comes in two varieties, normal (all data is represented as ASCII text) and raw (the image data itself is stored as packed bytes.) CHILS handles all six permutations. These formats have only one flag, which is "R" for a raw file and "N" for a normal file, and is redundant. The number of colors is expressed either as a number or as the number of bits per pixel. For PBM and PGM images, it is always a number (always 2 for PBM). For PPM images, it is either a number or the number of bits depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. There are no format-dependent displays for PBM; PGM and PPM display the maximum value that a pixel may take (usually a power of 2 minus 1). In the first example, the format is Raw PBM. The file is 29 bytes long. The image is 24 pixels wide by 7 high. The image uses up to 2 colors. The filename is "feep-raw.pbm". In the second example, the format is Raw PGM. The file is 180 bytes long. The image is 24 pixels wide by 7 high. The image uses up to 256 colors. The maximum value for a pixel is 255. The filename is "feep-raw.pgm". In the third example, the format is Raw PPM. The file is 59 bytes long. The image is 4 pixels wide by 4 high. The image contains 24 bits of color information per pixel. The maximum value for any of the three color components is 255. The filename is "feep-raw.ppm". In the fourth example, the format is Normal PBM. The file is 355 bytes long. The image is 24 pixels wide by 7 high. The image uses up to 2 colors. The filename is "feep.pbm". In the fifth example, the format is Normal PGM. The file is 519 bytes long. The image is 24 pixels wide by 7 high. The image uses up to 16 colors. The maximum value for a pixel is 15. The filename is "feep.pgm". In the sixth example, the format is Normal PPM. The file is 189 bytes long. The image is 4 pixels wide by 4 high. The image uses up to 4096 colors. The maximum value for any of the three color components is 15. The filename is "feep.ppm". 4.8 XBM ------- XBM 182 24 x 7 @ 2 'feep' feep.xbm The XBM (X BitMap) format is used by the X Window system developed at MIT. The format is designed for easy incorporation into C-language programs and all data is represented as ASCII text. The XBM format has no flags. The number of colors is always 2, black and white. Format-dependent displays for XBM are the name of the image, which is encoded into the file. In the example, the format is XBM. The file is 182 bytes long. The image is 24 pixels wide by 7 high. The image uses up to 2 colors. The name of the image is feep. The filename is "feep.xbm". 4.9 WIN2BMP ----------- WIN2BMP - 630 32 x 32 @ 16 argh.bmp The WIN2BMP format is an obsolete format used by MS-Windows 2.x. The WIN2BMP format has one flag, which is "D" if the bitmap resource is discardable or "-" if it is not. The number of colors is expressed either as a number or as the number of bits per pixel, depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. There are no format-dependent displays for WIN2BMP. In the example, the format is MS-Windows 2.x BitMaP. The bitmap resource is not discardable. The file is 630 bytes long. The image is 32 pixels wide by 32 high. The image uses up to 16 colors. The filename is "argh.bmp". 4.10 OS2BMP11 ------------- OS2BMP11 - 5078 80 x 50 @ 256 256color.bmp The OS2BMP11 format is used by OS/2 1.1-1.3. The WIN3BMP and OS2BMP20 formats are loosely based on it. The OS2BMP11 format has one flag, which is "E" if the file size in the header does not match the present file size or "-" if it does. The number of colors is expressed either as a number or as the number of bits per pixel, depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. There are no format-dependent displays for OS2BMP11. In the example, the format is OS/2 1.1 BitMaP. The file size in the header matches the present file size. The file is 5078 bytes long. The image is 80 pixels wide by 50 high. The image uses up to 256 colors. The filename is "256color.bmp". 4.11 WIN3BMP ------------ WIN3BMP -- 5078 80 x 50 @ 256 256color.bmp WIN3BMP -- 630 32 x 32 @ 16 argyle.bmp The WIN3BMP format is used by MS-Windows 3.x. It is loosely based on the OS2BMP11 format and the OS2BMP20 format is based on it. The WIN3BMP format has two flags. The first one is "E" if the file size in the header does not match the present file size or "-" if it does. The second one is "-" for an uncompressed file, "4" if 4-bit run-length compression is used, or "8" if 8-bit run-length compression is used. The number of colors is expressed either as a number or as the number of bits per pixel, depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. Format-dependent displays for WIN3BMP are the compression ratio (for compressed files), the horizontal and vertical resolution (if present) and the number of important colors (if present and different from the number of colors in the colormap) "Innn". The compression ratio is computed by multiplying the height by the width, then multiplying that result by the number of bits per pixel, and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the size of the compressed data (maintained in the file header) is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. The compression ratio is accurate unless the file is corrupted. The horizontal and vertical resolution are in pixels per meter, displayed as "Xnnn,Ynnn". In the first example, the format is MS-Windows 3.x BitMaP. The file size in the header matches the present file size, and the image is uncompressed. The file is 5078 bytes long. The image is 80 pixels wide by 50 high. The image uses up to 256 colors. The filename is "256color.bmp". In the second example, the format is MS-Windows 3.x BitMaP. The file size in the header matches the present file size, and the image is uncompressed. The image is 630 bytes long. The image is 32 pixels wide by 32 high. The image uses up to 16 colors. The filename is "argyle.bmp". 4.12 OS2BMP20 ------------- OS2BMP20 --R- 5078 80 x 50 @ 256 256color.bmp The OS2BMP20 format is used by OS/2 2.0. It is an extension of the WIN3BMP format. The OS2BMP20 format has four flags. The first one is "E" if the file size in the header does not match the present file size or "-" if it does. The second one is "-" for an uncompressed file or "C" for a compressed file. The third one relates to the colormap format and should always be "R". The fourth one is "H" if a halftoning algorithm is specified, "-" otherwise. The number of colors is expressed either as a number or as the number of bits per pixel, depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. Format-dependent displays for OS2BMP20 are the compression ratio (for compressed files), the horizontal and vertical resolution (if present) and the number of important colors (if present and different from the number of colors in the colormap) "Innn". The compression ratio is computed by multiplying the height by the width, then multiplying that result by the number of bits per pixel, and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the size of the compressed data (maintained in the file header) is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. The compression ratio is accurate unless the file is corrupted. The horizontal and vertical resolution are displayed as "Xnnn,Ynnn dp?", where '?' should always be 'm' (for dots per meter). In the example, the format is OS/2 2.0 BitMaP. The file size in the header matches the present file size, the image is uncompressed, the colormap format is correct, and no halftoning algorthm is given. The file is 5078 bytes long. The image is 80 pixels wide by 50 high. The image uses up to 256 colors. The filename is "256color.bmp". 4.13 PCX -------- PCX_30 RC 4715 80 x 50 @ 256 C~114 CX 80,CY 50 color.pcx PCX_30 RC 191 24 x 7 @ 8 C~100 CX 24,CY 7 feepgray.pcx PCX_30 RC 152 24 x 7 @ 2 C~114 CX 24,CY 7 feepmono.pcx The PCX format was created by the ZSoft Corporation. CHILS recognizes PCX_25 (version 2.5), PCX_28 (version 2.8 without palette), PCX_28P (version 2.8 with palette), and PCX_30 (version 3.0). The PCX format has two flags. The first one should always be "R", indicating that the file is run-length encoded. The second one is "G" if the palette should be interpreted as grayscale or "C" if it should be interpreted as color. The number of colors is expressed either as a number or as the number of bits per pixel, depending on which fits in the available space. In the case of a plain number, not all colors may be used; the number should be regarded as an upper limit on the number of colors in the actual image rather than the actual figure. Format-dependent displays for PCX are the compression ratio and the horizontal and vertical resolution of the file creator, in that order. The compression ratio is computed by multiplying the height by the width, then multiplying that result by the number of bits per pixel, and dividing by 8 to obtain the number of bytes which the image data would occupy when uncompressed. Finally, the present file size minus the length of the PCX header is divided by the computed uncompressed size, which yields the size of the compressed image as a percentage of the uncompressed size. The compression ratio should be accurate unless the file has extra characters (such as a 256-color palette) on the end. The horizontal and vertical resolution are displayed as "CXnnn,CYnnn". Unfortunately, it is not clear what these values mean. In the first example, the format is PCX 3.0. The image is run-length encoded as expected, and the colormap is color. The file is 4715 bytes long. The image is 80 pixels wide by 50 high. The image uses up to 256 colors. (((80 * 50) * 8) / 8) = 4000. ((4715 - 128) / 4000) = 1.14, so the compressed image is 114% of the size of the uncompressed image, in theory. The horizontal and vertical resolution of the creator are 80 and 50, respectively. The filename is "color.pcx". In the second example, the format is PCX 3.0. The image is run-length encoded as expected, and the colormap is color. The file is 191 bytes long. The image is 24 pixels wide by 7 high. The image uses up to 8 colors. (((24 * 7) * 3) / 8) = 63. ((191 - 128) / 63) = 1.00, so the compressed image is 100% of the size of the uncompressed image, in theory. The horizontal and vertical resolution of the creator are 24 and 7, respectively. The filename is "feepgray.pcx". In the third example, the format is PCX 3.0. The image is run-length encoded as expected, and the colormap is color. The file is 152 bytes long. The image is 24 pixels wide by 7 high. The image uses up to 2 colors. (((24 * 7) * 1) / 8) = 21. ((152 - 128) / 21) = 1.14, so the compressed image is 114% of the size of the uncompressed image, in theory. The horizontal and vertical resolution of hte creator are 24 and 7, respectively. The filename is "feepmono.pcx". 5. THE END ---------- Technical support via email is available from the following addresses: INTERNET (the following are alternate addresses for the same place): support@picarefy.com picarefy!support@amc.com picarefy!support@netcom.com uunet!uw-coco!amc-gw!picarefy!support COMPUSERVE: 71261,1731 GENIE: J.BIRDSALL2 Registrations should be sent to: James W. Birdsall 11112 NE 124 LN #D204 Kirkland, WA 98034 If you have an email address on any of the networks listed above, please include it when registering. It is much easier to send updates by email. Also, please specify what sort of archive (ZIP, ZOO, ARC, LZH, ARJ, UNIX shar) you can handle most easily. NOTE: IF YOU DO NOT PROVIDE AN EMAIL ADDRESS, YOU WILL ONLY RECEIVE MAJOR VERSION UPDATES. YOU WILL NOT RECEIVE MINOR VERSIONS. PLEASE PROVIDE AN EMAIL ADDRESS IF YOU HAVE ANY WAY OF DOING SO.